fix(runtime): honour allowReserved on path parameters - #112

Problem

The runtime percent-encodes every reserved character in a path parameter value, including /, regardless of the parameter's allowReserved flag. The planner already records allow_reserved on the operation descriptor for path parameters (allow_reserved = true appears in the emitted _OP_* tables), but _path_parameter never looked at it.

OAS 3.2 lists allowReserved under the path-parameter branch of the Parameter Object (styles-for-path in schemas/oas-3.2.json), so honouring it there is conformant rather than an extension: reserved characters go on the wire as-is. It matters for documents whose path parameter is itself a slash-delimited path — Open Policy Agent's /v1/data/{path} is the motivating case (path is some/document/path, and the openapi-generator client needed escape_path_params=false for it). Without the flag the server sees a single %2F-joined segment and returns an empty result.

Version caveat

The three bundled spec schemas disagree about whether the field is legal on a path parameter. Verified by generating a client and a server from a document declaring it, under the default strict = true:

This matters most for the MIGRATION.md row, which targets people coming off 0.2.x escape_path_params = false and who are likely to hold a 3.1 spec: they hit a load error rather than the feature.

Change

• _path_scalar / _path_array / _path_object / _path_parameter take allow_reserved and pass it to _escape, which already implements the reserved-set pass-through for query parameters. _append_parameter! forwards descriptor.allow_reserved on both path branches (plain and content-serialized).
• Everything else is still percent-encoded ("opa/examples/public servers" → opa/examples/public%20servers); the default (allowReserved absent or false) is unchanged.
• Unit tests for simple/label/matrix styles and an HTTP integration test asserting the request target.
• docs/src/clients.md documents the behaviour and the version caveat; MIGRATION.md gains a row for the 0.2.x escape_path_params = false option, noting the 3.0/3.2 requirement.
• Version 1.1.1. No generated code changes: the descriptor already carried the flag, so existing generated clients pick the fix up on upgrade.

Known gap: servers (#113)

This is a client-side fix. A generated server built from the same document cannot route the value the client now sends: register! mounts the path template as written and HTTP.Router matches {name} against a single segment, so the request 404s before reaching _decode_path_parameter.

/documents/opa%2Fexamples%2Fpublic%20servers  -> 200   (previous wire form)
/documents/opa/examples/public%20servers      -> 404   (what the client now sends)

Client and server generated from one document therefore cannot talk to each other for such a parameter. _decode_path_parameter is not at fault — given the full multi-segment text it already decodes correctly; only the route shape is wrong. The fix is constrained (HTTP.jl's ** must be the last path segment, and contributes nothing to getparams), so it is tracked separately in #113 rather than bundled here. docs/src/servers.md records the limitation in the meantime.

Full test suite passes locally on Julia 1.12.